ShareWare OnLine 2

home *** CD-ROM | disk | FTP | other *** search

/ ShareWare OnLine 2 / ShareWare OnLine Volume 2 (CMS Software)(1993).iso / games1 / fsstruct.zip / FSSTRUCT.ADD next >

Wrap

Text File | 1993-01-11 | 44KB | 1,144 lines

MICROSOFT FLIGHT SIMULATOR DATA FILE STRUCTURES INTERIM UPDATE Document version 2.2, release date: INTRODUCTION This document is a partial copy of FSSTRUCT.TXT ver. 2.2, yet to be released. It contains only the parts with significant enhancements and excludes parts that underwent only cosmetic changes. I would be grateful if you can let me have any suggestion, addition or corre- tion you think has to be included in the next release of FSSTRUCT, possibly within 2-3 weeks. It seems to me that the areas which most require our attention are (in a probable order of importance): ∙ variables: their contents and usage ∙ records remaining to be understood. Limiting ourselves to F1, there are 3 of them: 0C, 0F, 2E; I'm inclined to believe that 0C and 2E are rather unimportant; as Andrew Tuline pointed to me, 0F is probably very important and related to the overall relationship among scenery procedures. ∙ procedure relationships themselves; how procedures are selected for execu- tion? how procedures belonging to the same region are grouped and properly layered? It is probable that the answers to these questions and to other issues outlined in the last section of this document (Notes on file struc- tures) lie in the sceneries themselves. To these points is also related the meaning of 36 and 3C records. ∙ "duplicated" records: what is difference between records 0B and 4B, 17 and 19, 18 and 1F, 2F and 4A, 3D, 3E and 42? ∙ records only partially understood. They are: 04, 10 and 27, 13 and 14, 28, 43, 45 plus the record found only in SC1 (62) and SEE sceneries (4C, 4D, 4E, 52, 58, 6F). About these, I would like to draw Dan's attention to records 10, 27 and 43, because they seem to me to contain a trick similar to the one he discovered in rec 5A. ======================================== Appendix: Listing of all the occurrences of record 0F in F1 0001C2 0F 07 06 77 01 00 0001EB 0F 25 06 4E 01 00 0001FD 0F 02 06 3C 01 00 00021E 0F 0A 06 1B 01 00 000227 0F 09 06 12 01 00 000248 0F 0E 06 F1 00 00 000251 0F 0F 05 E8 00 00 000269 0F 16 05 D0 00 00 00027B 0F 15 06 BE 00 00 00028D 0F 08 04 AC 00 00 0002EE 0F 1B 08 4B 00 00 000318 0F 23 05 21 00 00 000321 0F 1E 05 18 00 00 00032A 0F 24 07 0F 00 00 000333 0F 01 06 06 00 00 0061B7 0F 06 06 06 00 02 00DBE0 0F 0D 01 09 0E 01 00DC6B 0F 0D 01 7E 0D 01 00DCF3 0F 0B 02 F6 0C 01 00DDB3 0F 0B 02 36 0C 01 00E04B 0F 0D 01 9E 09 01 00E11F 0F 0D 01 CA 08 01 00E19F 0F 0C 01 4A 08 01 00E264 0F 0C 01 85 07 01 010126 0F 11 01 5C 14 01 0101F2 0F 11 01 90 13 01 0102D3 0F 10 01 AF 12 01 0103B1 0F 10 01 D1 11 01 011F1D 0F 13 01 25 0D 01 011FD4 0F 13 01 6E 0C 01 01218C 0F 14 01 B6 0A 01 012251 0F 14 01 F1 09 01 0122D0 0F 12 01 72 09 01 012396 0F 12 01 AC 08 01 015984 0F 17 02 14 0A 01 015A26 0F 17 02 72 09 01 015AE3 0F 18 01 B5 08 01 015B69 0F 18 01 2F 08 01 016209 0F 19 02 8F 01 01 01BB03 0F 21 03 12 00 01 01BB0C 0F 1D 04 09 00 01 01CF85 0F 22 02 86 06 02 01D0E8 0F 1C 01 23 05 02 01EEE9 0F 20 02 07 13 01 01EF3F 0F 1F 02 B1 12 01 01F0F9 0F 1A 02 F7 10 01 0220B0 0F 04 06 31 00 01 0220CE 0F 05 06 13 00 01 0220D7 0F 03 06 0A 00 01 As you may see, byte 1 varies in the range 00h - 25h and there are 26h proce- dures in F1. ===================== FSSTRUCT.ADD BEGIN ============================= . . FS COORDINATES AND GEOGRAPHIC UNIT . . ∙ DELTA (2 bytes): a word representing the difference from an actual reference coordinate given elsewhere (usually in a previous ref. point record 24h). Delta coordinates have not a fixed magnitude, but depend on scale factor (usually set with byte 1 of record 24h): for scale factor 0, delta coor- dinates are aligned with the fractionary word of fract. FSu, for scale factor 8, delta coordinates are aligned with the integer word of fract. FSu, and for intermediate scale factors intermediate alignments are used; for a detailed discussion, see below under record 24h description. Contrarily to the other two representations, which are always positive, this representation is signed. This representation is indicated as "delta FSu". . . . VARIABLES FS apparently mantains somewhere in memory a set of 16-byte variables, which affect the display engine and/or the flight simulation engine. These vari- ables are accessed with a value which looks like a memory address and has been called "variable address". Attested addresses are in the range 0280h - 0364h. Variables can be set and tested from within a scenery file. Attested variables in F1 and SC1: 0280 read 48 times in F1, never written 0282 checked 45 times in F1, never written 0284 Crash flag: when this var is set to a non-0 value, the plane crashes; the displayed message depends on the value: 2 "mountain crash" 6 "building crash" 8 "splash" Ah "crash - lower your gear next time" Any other value results in a simple "crash" message 0286 tested 46 times in F1 against 1 0288 set to 0001 in SC1 fuel boxes; set 15 t. to 1 and once to 2 in F1 028A FS version number (0300h = 3, 0400h = 4, 040Bh = 4b), never accessed in F1 028C holds the daytime code (2 = day; 4 = night; 6 = dusk)? In F1 tested 118 t. against 1, 42 t. ag. 2, 45 t. ag. 3, once ag. 4, 32 t. ag. 6; set 5 t. to 1, set 6 t. to var 02D0 value 028E In F1, set 1 time to 1111h 0290 Low word of current view point East coord. Never accessed in F1, but var 0291 (spanning over MSB of var 0290 and LSB of var 0292) is checked once 0292 High word of current view point East coord. Checked very often in F1, but obviously never written 0294 Low word of current view point East coord. Never accessed in F1, but var 0295 (spanning over MSB of var 0294 and LSB of var 0296) is checked twice 0296 High word of current view point Alt. coord. Checked many times in F1 (9 times even for negative values), but obviously never written 0298 Low word of current view point North coord. Never accessed in F1, but var 0299 (spanning over MSB of var 0298 and LSB of var 029A) is checked once 029A High word of current view point North coord. Checked very often in F1, but obviously never written 029C Current delta East from last ref. point 029E Current delta Alt. from last ref. point 02A0 Current delta North from last ref. point 02A2 - 02AA Never accessed in F1 02AC Checked 15 t. in F1, always in the S. Francisco area. It is perhaps related to the view direction 02AE - 02CE Never checked or set in F1; values of vars 02AE - 02BE, however, are sometime assigned to other vars. 02D0 - 02E0 These seem to be 'spare' vars, used here and there to hold temporary values or copies of other vars' values 02E2 Surface fill colour; the colour code is repeated in all the four nibbles. In F1, the var is set very often to literal colour codes and it is also loaded once with the value of var 02C2, 6 t. with value of 02E0, 25 t. with value of 02E6, 8 t. with value of 02E8, twice with value of 02EA, and 4 t. each with values of 0314, 0316, 0318, 031A 02E4 In F1 set 16 times to 5555h and 16 times to FFFFh 02E6 Perhaps holds the current water colour (which changes with day time); in F1 it is set 16 times to 0000 and 16 times to the value of var 02C2 02E8 Perhaps it holds some standard colour; in F1 it is set 16 t. to 0000, 14 times to AAAAh, 9 t. to the value of 02C4 and 9 t. to the value of 02CC 02EA Same as 02E8; in F1 it is set 16 t. to 0000 and 16 t. to the value of var 02C6 02EC In F1 it is set once to 0023h, once to 0046h, once to 0089h 02EE Low word of above sea level altitude of current area in m. Never used in itself but, var 02EF (spanning over MSB of 02EE and LSB of 02F0) is set in SC1 runways and 155 times in F1 (with values from 0000 to 0776h). 02F0 High word of 02EE. Same observations. 02F2 In F1 it is set 29 t. to values from FEEFh to F667h and from 0000 to 0FA4h. It clearly holds a signed value. 02F4 In F1 is is set 13 t. to values from F555h to FD28h and from 0000 to 0FA4h. It clearly holds a signed value and is perhaps related to the previous var. HYPOTHESIS: both vars are related to 'cant'. 02F6 Set to 0001 in SC1 inner markers, never reset. Never used in F1. 02F8 Set to 0001 in SC1 outer markers, never reset. Set 26 times in F1. 02FA Set to 0001 in SC1 middle markers, never reset. Set 29 times in F1. 02FC Set to glideslope in ILS of .SCN files. Set 9 t. in F1 where, however, the record 4Fh is also used 25 times 02FE Set to approach course in ILS of .SCN files. Set 9 t. in F1 where, however, the record 4Fh is also used 25 times 0300 In F1, set twice to 0004, twice to 0005, 7 t. to 0007. Never read 0302 In F1, tested 16 t. against -1 and 6 t. against var 0304 value. Never set 0304 In F1, tested 6 t. against var 0302 value. Never set 0306 In F1, tested 16 t. against -1. Never set 0308 In F1, tested 16 t. against var 0280 value. Never set 030A - 0310 Apparently never used in F1 or in SC1 files 0312 Set to 0001 by SEE before some lists of 1Fh subroutine calls. Used in F1 as a 'spare' var to hold temporary values or a copy of another var value (often a delta altitude) 0314 - 031C Used in F1 as 'spare' var 031E Set to 0000 and 0001 in SC1 mountains. Unused by F1 0320 In F1 tested 4 t. against 1; set 3 t. to 0000 and 3 t. to 0001 0322 - 034C Apparently never used in F1 or in SC1 files 034E In F1 tested once against -1; tested against -1 in SEE custom objects (with 23h records) and in SC1 buildings (with 28h 36h records). 0350 - 0362 Apparently never used in F1 or in SC1 files 0364 Perhaps holds the scenery detail level (0 sparse, 1 medium, 2 com- plex). In F1 tested 3 t. against 2 and 3 t. against 3 BYTE OFFSET Many records contain an offset, pointing to another record. It is used to provide some forms of inter-record addressing for conditional (after variable test) or unconditional jumps. These offsets are indicates as "bytes offset" and are always relative to first byte (code byte) of the record which con- tains them. ====================================================================== SCENERY DESCRIPTION LANGUAGE STATIC RECORD CODE REFERENCE Static records are used in three types of files, all related to static scenery descriptions: the default scenery (F1), alternate sceneries (.SCN) and ASD static sceneries (.SC1). Actually, it contains ALL the records found in F1, SD-EUR.SCN and unenhanced .SC1 files. While static records are geared toward scenery display, they make a real pro- cedural programming language, which we call Scenery Description Language (SDL), with variable tests, conditional and unconditional jumps, subroutine calls and so on. Scenery files are made of several scenery procedures and, within FS4, an SDL processor 'executes' them to display the scenery and perhaps to act on the flight simulation itself. Procedure entry points are listed at fixed loca- tions of .SC1 and F1 files; such a table has not been localized yet for .SCN files. Given the procedural nature of SDL, scenery objects do not usually have a fixed structure, but are made of the SDL statements (records) required to 'build' them, with the notably exception of unenhanced .SC1 files, which objects, perhaps to make the job of the ASD editor easier, follow standard record patterns. In the following reference, all records found in F1, SD-EUR and unenhaced .SC1 files are listed; some records from SEE enhanced .SC1 files are also added; for several records, however, the meaning is unknown and only the length has been determined. Record are listed by code. Field at offset 0 always contains the record code and is 1 byte long. Records found only in SD-EUR are marked with =SCN=, records found only in SEE enhanced sceneries are marked with =SEE=, records found only in SC1 files are marked with =SC1=, while records found, even not exclusively, in the default scenery F1 are con- sidered part of the 'basic' SDL and not marked. Record description contributed by Dan Samuel are marked with an DS. -- 00h ------------- Flashing light (7 bytes) 1 2 E coord (delta FSu) 3 2 A coord (delta FSu) 5 2 N coord (delta FSu) Places a flashing light at the delta point. Light colour is given by a previous record 12h. -- 01h ------------- Move pen to 3D point (7 bytes) -- 02h ------------- Draw to 3D point (7 bytes) 1 2 E coord (delta FSu) 3 2 A coord (delta FSu) 5 2 N coord (delta FSu) These records, resp., move the pen and draw a line to a 3D point given rela- tively to a previous ref. point. -- 03h ------------- Simple runway (6 bytes) 1 1 heading 2 2 half-length in m 4 2 half-width in m Draws a simple black runway with a dashed line in the middle. -- 04h ------------- ???-point list (variable) This record is used in F1 (only 4 times) after some points are defined with 31h records and it contains, after the record code, only a list of points (indicated by their numbers); the list is of variable length and is terminated by a FFh byte. -- 05h ------------- NDB (11 bytes) 1 2 frequency; BCD coded (ex.: 327 kHZ -> 27h 03h) 3 4 N coord. (fract. FSu) 7 4 E coord. (fract. FSu) Note that coordinates are reversed (first North, second East) with respect to other nav aid records. -- 07h ------------- ??? (1 byte) =SCN= Used only once in SD-EUR -- 0Bh ------DS----- Unconditional jump (3 bytes) 1 2 byte offset This record tells FS to jump over a given amount of bytes, avoiding the execution of some SDL statements. It is usually used after a test record to providing branching to another point of the object definition. It is also used in .SC1 to unconditionally skip over 2-byte "signatures" inserted by ASD, usually before building descriptions, and not intended to be executed: they are probably only a help for the editor to recognize the kind of object; Steve Turley advised me that record 0Bh is used in SEE files to skip over ASCII "comments". Both kinds of non-SDL embedded material make the life difficult for scenery parsing utilities; the only way I found to deal with them is to keep track of referenced record addresses and to skip to the given byte offset if the address of the record after the 0Bh record is not referenced by any previous SDL statement, but caveat: some backward byte offset have been detected in F1. -- 0Ch ------------- ??? (3 bytes) Used only twice (at offsets 00BBF1 and 00D8E5) in F1, always after a 2Eh record and always in the form: 2E 09 80 0C 05 50 -- 0E/8Eh ---------- Delayed subroutine call (3 bytes) 1 2 byte offset This record has been one of most difficult to understand. It is basically a subroutine call, but the referenced address is not called immediately, it is collected in some kind of stack; at some point, presumably during the execu- tion of a 79h record, all the collected routines are sorted in order of decreasing distance of the object they draw from the view point and executed. For the sorting to be effective, referenced routines have to begin with a ref point record (24h); if a routine lacks this record, it is executed first. This record is extensively used to collect groups of routines drawing build- ings and other elevated objects and provides a simple way to draw them in a perspective correct fashion. Record 0Eh is consistently used in .SC1 files in a way that makes such a behaviour very unclear, because each 0Eh, in .SC1, is followed by a 0Bh record which jumps over the routine referenced in the 0Eh record; sometime between the routine proper and the 0Bh record a 2-byte "signature" is enclosed (see above, under 0Bh record). Not used in SC-EUR. -- 0Fh ------------- ??? (6 bytes) Used 49 times in F1. -- 10h ------------- Hidden surface check (5 bytes) 1 2 byte offset 3 1 point number 4 1 control vector number Not fully understood. This record jumps to the given offset if the point which number is given in byte 3 is aligned in some fashion, from the current view point, with the control vector which number is given in byte 4. The point has been previously defined by a record 31h and the vector has been defined by a record 27h. Practically, if the vector is defined correctly, the record 10h checks if the surface associated with the vector is visible or not from the current view point. See also discussion of record 27h. -- 12h ------------- Line Colour (2 bytes) 1 1 colour code from the following table: 0 Black 1 Dark Green 2 Dark Blue 3 Dark Cyan 4 Orange 5 Light Grey 6 Light Blue 7 Cyan 8 Brown 9 Yellow Ah Dark Grey Bh Light Green Ch Red Dh Gold Eh (apparently not used/transparent?) Fh White -- 13h ------------- Daytime line colour (10 bytes) 1 1 line colour for day time 2 1 line colour for dawn time 3 1 line colour for night time 4 3 second colour triplet 7 3 third colour triplet This record applies to following lines different colours for different daytimes; its effect ceases at the next 12h record. In F1, the second and third colour triplets are filled with consistent pat- terns of colours, but, during my tests, their colours never shown up nor affected in any way the first three. -- 14h ------------- Daytime surface colour (10 bytes) 1 1 surface colour for day time 2 1 surface colour for dawn time 3 1 surface colour for night time 4 3 second colour triplet 7 3 third colour triplet All colour codes are repeated in both nibbles. This record applies to following surfaces different colours for different daytimes; its effect ceases when variable 02E2h is set by a 25h record. In F1, the second and third colour triplets are filled with consistent pat- terns of colours, but, during my tests, their colours never shown up nor affected in any way the first three. -- 15h ------DS----- Axis roto-translation (15 bytes) =SEE= 1 2 angle around E axis 3 2 angle around N axis 5 2 angle around A axis 7 2 delta E (delta FSu) 9 2 delta A (delta FSu) 11 2 delta N (delta FSu) 13 2 byte offset The same observations made for record 16h apply to this record also. With it, local coordinate system is both rotated and translated. -- 16h ------------- Axis rotation (9 bytes) 1 2 angle around E axis 3 2 angle around N axis 5 2 angle around A axis 7 2 byte offset This record is one of the most ingenuous: it applies to the local coordinate system (used for delta FSus, and by default centered in the ref. point and parallel to global axes) the described rotations, then it calls the referenced subroutine: anything (not only buildings) drawn by this routine with delta coords. will appear rotated; when the subroutine returns, the coordinate system is restored. The record can be used to display tilted objects with a very small code overhead. -- 17h ------------- Return17 (1 byte) This single byte record returns from a subroutine; its difference from record 19h is not clear. In .SC1 it has been observed only in timing gate definitions, but in F1 it is used 27 times in various contexts. -- 18h ------------- Call18 (3 bytes) 1 2 byte offset (subroutine address) Calls a subroutine; its difference from record 1Fh is not clear. Used 624 times in F1. -- 19h ------------- Return19 (1 byte) This single byte record returns from a subroutine; its difference from record 17h is not clear. Used 312 times in F1. -- 1Ah ------------- Equ var (5 bytes) 1 2 var1 address 3 2 var2 address Very probably, this record set var1 to the value of var2. -- 1Bh ------------- Line night colour on (1 byte) This record set the night and dawn colours of following lines to a standard colour (in FS4, light blue). Its effect ceases with the next record 12h. -- 1Ch ------------- Line night colour off (1 byte) Restores the night and dawn colours of following lines to the same colour used for day. -- 1Dh ------------- VOR (11 bytes) 1 2 frequency; BCD coded (ex.: 109.15 MHz -> 15h 09h) 3 4 E coord. (fract. FSu) 7 4 N coord. (fract. FSu) -- 1Eh xxxx -------- ATC message (xxxx bytes) 1 2 record length 3 2 frequency; BCD coded (ex.: 127.15 MHz -> 15h 27h) 5 4 4 runway numbers (often repeated) 9 4 ?? 13 var message text (0-terminated) The message text can include any character from ASCII 20h to ASCII 93h. Characters greater than 93h result in garbage being transmitted. When the message is played back, characters from 80h to 93h are expanded into the fol- lowing strings (stored in ATC.FS4): 80h " Whether - " 81h " OBSERVATION " 82h " XX:00 ZULU " (where XX is replaced by the current hour time) 83h "" (empty string) 84h " TEMPERATURE 25 - " 85h " INFORMATION " 86h " LANDING AND DEPARTING RUNWAY XX - " (where XX is replaced by the runway number given at offset 5) 87h " ADVISE CONTROLLER " 88h " ALTIMETER 29.95 - " 89h " VISIBILITY 10 - " 8Ah " WIND XXX at YY - " (where XXX and YY are replaced by wind direction and speed defined by the wind menu or generated by the weather generator; if both are off, this character is ignored) 8Bh " MEASURED CEILING 00600 OVERCAST " 8Ch "" (empty string) 8Dh "" (empty string) 8Eh "Microsoft Flight Simulator" 8Fh " requesting " 90h "clearance " 91h ", your are cleared " 92h "... " 93h "7777 " -- 1Fh ------DS----- Call1F (3 bytes) 1 2 byte offset (subroutine address) Subroutine call; its difference from record 18h is not clear. Used 192 times in F1. -- 20h ------------- Jump if var outside (9 bytes) 1 2 byte offset 3 2 var address 5 2 value1 7 2 value2 This record jumps over the given amount of bytes, if the value of the vari- able at the given address is outside the range value1 - value2. -- 21h ------------- Jump if 2 vars outside (15 bytes) 1 2 byte offset 3 2 var1 address 5 2 min1 value 7 2 max1 value 9 2 var2 address 11 2 min2 value 13 2 max2 value This record jumps over the given amount of bytes, if var1 is outside the range min1 - max1 OR var2 is outside the range min2 - max2. -- 22h ------------- Jump if 3 vars outside (21 bytes) 1 2 byte offset 3 2 var1 address 5 2 var1 min value 7 2 var1 max value 9 2 var2 address 11 2 var2 min value 13 2 var2 max offset 15 2 var3 address 17 2 var3 min value 19 2 var3 max offset This record is similar to the previous, but involves 3 variables. -- 23h ------------- NAND Jump (7 bytes) 1 2 byte offset 3 2 var address 5 2 value Jumps if the bitwise AND of the given var value and the given value is 0. -- 24h ------------- Reference point (14 bytes) 1 1 scale factor 2 4 E coord. (fract. FSu) 6 4 AGL alt. (fract. FSu) 10 4 N coord. (fract. FSu) A reference point record is a temporary coordinate origin for delta FSunits. It is used within the definitions of some kinds of object to define a point in 3D, near the center of the object; other points of the object are then defined relatively to this point. Byte 1 is a scale factor determining delta unit magnitude: Factor 1 delta unit is 00 1/256 m 01 1/64 m 02 1/16 m 03 1/4 m 04 1 m 05 4 m 06 16 m 07 64 m 08 256 m (1 delta u = 1 FSu) .SC1 files use only factor 04 (plus factor 02 in fuel boxes only); F1 uses factors 02, 04, 06, 08; all other factors have been tested manually. -- 25h ------DS----- Set variable (5 bytes) 1 2 variable address 3 2 new variable value Sets the given variable to the given value. -- 27h ------------- Define control vector (8 bytes) 1 2 x coord 3 2 z coord 5 2 y coord 6 1 vector number Defines a control vector related to a surface about to be drawn and assign to it a number in a point list; the vector so defined is afterward checked by a record 10h some way against one of the points of the object, if the check fails, a jump is triggered. Obviously, both records 10h and 27h are related to hidden surface removing, but I didn't understand the geometrical relation among the surface, the vector and the point, which can be similar to triangle vector of the 5Ah record. -- 28 -------------- Compare vars (8 bytes) 1 1 value: condition: 02 var1 > var2 ? 04 var1 < var2 ? 2 2 byte offset 4 2 var1 6 2 var2 Jumps to the given byte offset if the condition is true. Var values are treated as unsigned (8000h > 7FFFh). In SC1 buildings, a record 28h in which condition value = 36h, var1 = 034Eh, var2 = FFFFh is often used; in this case, var2 is obviously a literal value, but the performed test is not clear. -- 29h ------------- Close path (1 byte) This record, made of the single byte 29h, is used to close a path being drawn with 40h and 41h records. A line is drawn from the current point to the starting point of the last executed 40h record. If the path begun with sur- face record (2Fh), the path is filled with the colour stored in var 02E2. -- 2Ah ------------- Dotted line (14 bytes) 1 2 P1 E coord. (delta FSu) 3 2 P1 A coord. (delta FSu) 5 2 P1 N coord. (delta FSu) 7 2 P2 E coord. (delta FSu) 9 2 P2 A coord. (delta FSu) 11 2 P2 N coord. (delta FSu) 13 1 Number of points / 2 This record draws a dotted line from P1 to P2, containing twice the number of points given at byte 13. -- 2Bh ------------- Dashed line (14 bytes) 1 2 P1 E coord. (delta FSu) 3 2 P1 A coord. (delta FSu) 5 2 P1 N coord. (delta FSu) 7 2 P2 E coord. (delta FSu) 9 2 P2 A coord. (delta FSu) 11 2 P2 N coord. (delta FSu) 13 1 Number of dashes This record draws a dashed line from P1 to P2, containing the number of dashes given at byte 13. -- 2Eh ------------- ??? (3 byte) Used only twice (at offsets 00BBEE and 00D8E2) in F1, always after a 0Ch record and always in the form: 2E 09 80 0C 05 50 -- 2Fh ------------- Surface (1 byte) This record, made of the single byte 2Fh, is used to start a surface perimeter. When the perimeter is closed with 29h record, the surface is filled with the current colour. -- 31h ------------- 3D-point (8 bytes) 1 1 point number 2 2 E coord (delta FSu) 4 2 A coord (delta FSu) 6 2 N coord (delta FSu) This record is used in F1 to define points in 3D. It also used in SC1 mountain descriptions to set mountain vertices (peaks are numbered from 01h to 0Fh, base points from 21h inward). -- 32h ------DS----- Move to 3D point (2 bytes) 1 1 point number Moves the pen (without drawing) to the point. Point numbers have been set by a previous 31h record. -- 33h ------DS----- Draw to 3D point (2 bytes) 1 1 point number Draws to the point. Point numbers have been set by a previous 31h record. -- 35h ------------- Dot (2 bytes) 1 1 point number Draws a dot at the given 3D point, prev. defined with a 31h record. -- 36h ------------- ??? (2 bytes) 1 1 always 00? This record occurs only once in F1 and SC-EUR, each time at the end of the special INIT scenery procedure. -- 3Bh ------------- Set elevation (5 bytes) 1 4 elevation level (fract. FSu) Set an elevation level above current ground level. Used in F1 to make elevated 'solid' surfaces, like the carrier deck or the Golden Gate. -- 3Ch ------------- ??? (4 bytes) This record occurs only once in F1 and in each SCN, each time at the beginning of the special INIT scenery procedure. Byte 2 contains the scenery number (FFh being the number of F1). -- 3Dh ------------- Jump if outside area (19 bytes) 1 2 byte offset 3 4 min E (fract. FSu) 7 4 max E (fract. FSu) 11 4 min N (fract. FSu) 15 4 max N (fract. FSu) Jumps if current plane position (not the view point) is outside the delimited rectangular area. -- 3Eh ------------- Jump if outside rectangle (Area record) (9 bytes) 1 2 byte offset 3 2 N coord. (int FSu) 5 2 E coord. (int FSu) 7 2 area semi-side (int FSu) Jumps if current plane position (not the view point) is outside the delimited rectangular area. The record tests for a rectangular area not a circular one. A 3Eh record starts the representation of each object in SC1 files and, in fact, it is the easiest way to avoid rendering an object if the aircraft is too away from it; however, as for any SDL record, it is a procedural state- ment and does not define an object property, it is not even mandatory: many times, in F1, several related objects are grouped within a single 3Eh rec, or a complex object is broken in many independently displayed parts. Sometimes, it is totally absent and the visibility of the object is checked by others ways. -- 40/C0h ---------- Move to 2D point (5 bytes) -- 41h ------------- Draw to 2D point (5 bytes) 1 2 E coord. of the point (delta FSu) 3 2 N coord. of the point (delta FSu) Move and draw records are used to draw line segments. A move record moves to the point given in the record without drawing anything, a draw record draws a line segment or a polygon boundary from the previous point to the given point. Within SC1 files, Move record code can be either 40h or C0h, without any visible difference. All coords are delta coords and are relative to a previously given ref. point record. -- 42h ------------- Jump if outside area (11 bytes) 1 2 byte offset 3 2 min E (int. FSu) 5 2 max E (int. FSu) 7 2 min N (int. FSu) 9 2 max N (int. FSu) Jumps if current plane position (not the view point) is outside the delimited rectangular area. The test only succeds if the map view is on. -- 43h ------------- ??? (29 byte) 1 2 byte offset 3 4 E coord (fract FSu) 7 4 A coord (fract FSu) 11 4 N coord (fract FSu) 15 14 ?? Used only 5 times in F1, 4 times after 00BF4C (around the Catalina I.) and 1 time at 01E1E1 (within Oakland Int'l). It seems to be a test based on some geometrical property of the given point. -- 44h ------------- Define array of points (15 bytes) 1 1 i, first point number 2 2 P1 E (delta FSu) 4 2 P1 A (delta FSu) 6 2 P1 N (delta FSu) 8 2 P2 E (delta FSu) 10 2 P2 A (delta FSu) 12 2 P2 N (delta FSu) 14 1 n, number of points Defines n points, consecutively numbered from i onward and evenly distributed on the 3D segment from P1 to P2. Used only 4 times in F1 to define the points for the 'net' on the side of the mountain in front of San Francisco. -- 45h xxxx -------- Thermal generator (xxxx bytes) 1 2 record length (0025h) 3 4 E coord of generator center (fract FSu) 7 4 altitude AGL of generator center ? 11 4 N coord of generator center (fract FSu) 15 2 orientation 17 1 ??? 18 2 generator width (in m) 20 2 ??? 22 2 thermal effect height (in feet) 24 2 ??? 26 2 generator length (in m) 28 9 ??? This record has been found only in thermal generators. Used 11 times in F1. -- 49h ------------- Runway end lights (20 bytes) 1 4 E coord (fract. FSu) 5 4 A coord (fract. FSu) 9 4 N coord (fract. FSu) 13 2 heading (in 182.04°) 15 1 light bits: 0 end lights 1 MALSR 2 REIL 3 VASI 4 moving strobes 5 ?? (irrelevant?) 6 ?? (irrelevant?) 7 ?? (irrelevant?) 16 1 moving strobe length (in ??) 17 2 VASI glide slope (in 1/10°) 19 1 ?? Places a runway end light system. -- 4Ah ------------- Surface4A ?? (1 byte) This single byte record is used to start a surface path; the difference with record 2Fh is not clear. Used 8 times in F1. -- 4Bh ------------- Jump4B ?? (3 bytes) 1 2 byte offset This record, used only once in F1, seems to be another jump instruction. Its difference with record 0Bh is not apparent. -- 4Ch ------DS----- ??? (2 bytes) =SEE= -- 4Dh xxxx--DS----- ??? (xxxx bytes) =SEE= 1 2 record length 3 4 E coord (fract FSu) 7 4 A coord (fract FSu) 11 4 N coord (fract FSu) 15 ?? ?? -- 4Eh ------DS----- ??? (4 bytes) =SEE= -- 4Fh ------------- ILS (15 bytes) 1 2 frequency; BCD coded (ex.: 109.15 MHz -> 15h 09h) 3 4 E coord. (fract. FSu) 7 4 N coord. (fract. FSu) 11 2 Approach course in 1/3° (0 -> 0, 359 -> 0435h) 13 2 Glide slope in 1/9100 (0 -> 0, 7.20 -> FFFFh) ----- The following records, up to 79h excluded, are never used in F1 but only in SC1 files, either standard or SEE enhanced; they may be an ASD extension, which ASD itself recognizes and converts to SDL routines before feeding them to the SDL processor, or they may be part of the standard SDL. ----- -- 50/D0h ---------- Runway (35 bytes) =SC1= See below under runway description for details. -- 51h ------------- Side list end (used in mountains, 1 byte) =SC1= -- 52h ------DS----- ??? (2 bytes) =SEE= -- 53h ------------- Building (variable) =SC1= The building record defines the aspect of a building; its length and struc- ture varies according to the building type. Here a summary is given, see below, under building descriptions, for details. 2nd byte building type and length 01 Rectangular building record (18 [flat] and 19 [peaked] bytes) 02 L building record (24 [flat] and 27 [peaked] bytes) 03 T building record (28 [flat] and 32 [peaked] bytes) 04 U building record (28 [flat] and 33 [peaked] bytes) 05 H building record (34 [flat] and 41 [peaked] bytes) 06 Reversed L build. record (24 [flat] and 27 [peaked] bytes) 07 Control tower record (20 bytes) 29 Tower record (6 bytes) 33 Suspended bridge record (8 bytes) 34 Bridge record (8 bytes) 3D Timing gate record (17 bytes) 42 Coniferous tree record (7 bytes) 43 Deciduous tree record (7 bytes) 47 Auto record (3 bytes) 4C Multi-sided building record (13 bytes) -- 58h ------DS----- 3D text (43 bytes) =SEE= 1 7 ??? 8 2 text size 10 32 text, 0-terminated 42 1 always 17h ?? (in that case, it could be another occurrence of the 17h record) -- 5Ah ------DS----- 3D-triangle (10 bytes) =SC1= 1 2 E component of the "triangle vector" (see below) 3 2 A component 5 2 N component 7 3 numbers of the 3 points, listed in anti-clockwise order looking to the triangle from outside This record is used in mountains and is probably used to speed up the hidden surface removing process. The "triangle vector" is the cross product of the vectors for the P2-P1 and the P3-P1 edges of the tiangle, the cross product is then scaled so that no coord value is > 16383. Point numbers at offset 7- 9 correspond to mountain vertices defines in a previous list of 3D points (list of 31h records). -- 62h ------------- ??? (10 bytes) =SC1= -- 6Fh ------DS----- ??? (11 bytes) =SEE= -- 79h ------------- SDL End (1 byte) Exits the SDL processor. Used in SC1 only at the end of each section, within F1 it occurs even in the middle of regions with a complex execution flow and multiple exit points (SDL is not structured, after all!); it cannot be used within subroutines, otherwise FS4 crashes. ====================================================================== NOTES ON FILE STRUCTURES GENERAL CONSIDERATIONS Sceneries are organized in a 'layered' way, each procedure being a layer (ground, runways and other signs on the ground, elevated objects like build- ings, ...) of a scenery region; layers are executed from the lowest to the highest, each layer covering the previously drawn. Procedure entry points are listed in the headers of SC1 files and of F1; presumably such a table exists also within SCN files. Sceneries must contain a way to determine to which region each procedure belongs (to avoid executing the full scenery at each frame generation) and in which order the layers of a region have to be drawn, but it has not been determined yet. Interaction between the base scenery and SC1 is complex: SC1 layers (presumably corresponding to the nine SC1 sections) are not executed together AFTER base scenery layers, because at least base scenery buildings are drawn after some SC1 additions: one can imagine that ASD, after selecting the SC1 file appropriate to the current plane position, intercepts FS4 calls to the SDL processor and intermixes calls to it passing the SC1 layers. ---------- F1 HEADER F1 begins with a header made of the elements listed below; given values come from ver. 4.0b; in any case, a manually made test empty scenery based on his structure has been accepted and executed by F4. 0000 02DD ?? 0002 00000106 0081 offset and length of the dialogue descriptor 0008 00000187 0028 offset and length of the INIT procedure 000E 00000000 0000 offset and length of UNKNOWN1 0014 00000000 0000 offset and length of UNKNOWN2 001A 00000000 0000 offset and length of UNKNOWN3 0020 0026 number of scenery procedures Then, a table is given with, for each scenery region: oooooooo llll offset and length of each procedure Table ends at 0106h. A descriptor of the dialogue window displayed when the scenery is selected follows, each text line is described by: 01 xxxx yyyy 00 "line text " 00 00 xxxx and yyyy being the video coordinates of the line starting point, in some sort of device independent unit of measure. A record: 00 marks the end of the descriptor. The dialogue is followed by what has been conventionally called the INIT pro- cedure: 0187 3C 00 FF 28 ??? 018B 21 0012 Jump to 019D if 0000 F470 FD80 var 0000 outside F470-FD80 or 0000 D972 E312 var 0000 outside D972-E312 019A 0B 0012 Jump to 01AC 019D 21 0012 Jump to 01AF (addr. of the 1st procedure) if 0000 EFEC FB8C var 0000 outside EFEC-FB8C or 0000 E312 EBEC var 0000 outside E312-EBEC 01AC 36 00 ??? 01AE 79 END SDL Processor After that, at 01AF, the first scenery procedure begins. The INIT procedure has been so called because it obviously enjoys a particu- lar status, having a pointer reserved to it in the header. Records 3C and 36 occur only there and therefore their meaning is difficult to identify. The routine itself is syntactically correct (known records follow the standard structures and referenced address correspond to record addresses) but the reference to var 0000 is surprising at least. ---------- NOT ON SCN FILES SCN files have a very different structure than F1. Generally speaking, the SCN structure seems to be an old leftover of the time when sceneries were loaded from floppy disks without the a secure DOS aid (FS was an auto-booting protected program). 0000-01FF Only garbage: some files contain a boot-strap sector, other just a lot of 79h records. 0200-02FF Still garbage or some initialisation values for FS variables 0300-03FF The first bytes contain the INIT procedure, with the same structure of F1's INIT (3Ch record, tests, 36h record, 79h record), but different test values (some SCN contain more than 2 tests); the last test points beyond the 79h record where no SDL code lies. The remaining part of this area does not have any apparent sense. 0400-.... Here the scenery proper begins. Scenery procedures are not consecutive, as in F1 and SC1, but, after the end of a procedure, the file is padded with garbage until the next kB boundary, where the next procedure begins. Sector 116 (beginning at 00E800h) contains the dialogue descriptor, with a similar but not identical structure to F1 dialogue's. It is well possible that in this area lies the procedure table also, but I was not able to find it. Given that SCN structure is obscure, contains a lot of padding garbage and is probably a relic of the past, I actually don't see any compelling reason to go significantly beyond the above outline, which, at any rate, makes possible a more or less easy, but complete, parsing of SCN files. It is worth noting also that a file may have an .SCN extension and still use the F1 structure, because FS4 correctly recognizes and executes F1 even if it is renamed with an .SCN extension. ==================== FSSTRUCT.ADD END ====================